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Description 

TECHNICAL FIELD OF THE INVENTION 

This invention relates to a system for managing 
available-to-promise product (ATP) and making promis- 
es to fulfill customer requests. 

Manufacturers produce products for sale to custom- 
ers. In the sales process, customers place demands on 
manufacturers. A customer demand may consist of a 
request for a particular quantity of a product by a specific 
date. This date and quantity information may be collec- 
tively referred to as the "customer request" or "request 
information". 

Manufacturing and distribution facilities have limit- 
ed resources (capacity)and limited inventories (materi- 
als). Therefore, every customer request may not be sat- 
isfiable in that some may receive no promise, others 
may receive an inadequate one. Planning and manag- 
ing which customer requests to promise and fulfill, 
termed "demand management", is a fundamental and 
critical activity of most manufacturing and distribution or- 
ganizations. 

Due to material, capacity and other limitations, a 
manufacturer may not be able to meet a particular cus- 
tomer request. In this situation, the manufacturer typi- 
cally negotiates with the customer to deliver a quantity 
of product by one or more dates agreeable to the cus- 
tomer. This date and quantity information may be re- 
ferred to as the "manufacturer promise" or "promise in- 
formation". Based on the manufacturer promise, the 
manufacturer creates operational plans to implement 
the promise information. Manufacturers may use a com- 
bination of diverse software tools in the negotiating and 
planning processes. 

Traditional methods for demand management have 
several problems. First, such methods and systems are 
not integrated. Several different tools may be required 
to implement the entire demand management strategy. 
Second, such traditional systems and methods are not 
dynamic. Once a plan is in place, it is difficult for the 
manufacturer to react to changing circumstances and 
update the plan. Third, order promising to customers is 
often done based upon an infeasible plan. Later at- 
tempts to find a feasible plan that will satisfy the prom- 
ises are often futile. 

The environment today requires more and more re- 
sponsiveness. Customers require significant product di- 
versity and want promises to be made to their requests 
immediately, while on the phone. The traditional way of 
promising in configure-to-order or make-to-order envi- 
ronments involves submitting the request to the plan- 
ners and then, a few days or weeks later, after the plan- 
ners have gone through a planning cycle, receiving a 
promise or rejection. 

Many manufacturing and distribution organizations 
have several sales offices associated with each manu- 
facturing factory. Each sales office independently prom- 



ises to supply products from the factory to customers. 
This is referred to as a "distributed organization". Each 
sales person in each of the sales organizations needs 
to be able to make instantaneous promises, simultane- 
s ously with other sales people doing the same. In addi- 
tion, each of those promises need to be fulfillable by a 
feasible plan. 

To better meet customer demand, the manufacturer 
must build product and/or intermediate items before re- 
10 ceiving customer orders. This production is based on 
projections called "forecast orders". A product produced 
based on these forecast orders is referred to as "avail- 
able to promise" or "ATP". ATP consists of quantities of 
products with associated dates that the products are 

J5 scheduled to be available for delivery to the customer. 
In distributed organizations a sales office may need 
approval from the factory before ATP may be promised 
to meet a customer request. This approval process may 
take up to a week under current practices. This delay is 

20 unacceptable in today's business environment. 

European application EP-A-0,425,405 describes 
an automated customer order promising and confirming 
method. The order promising and confirming method 
automatically interfaces a production planning system 

25 to provide an integrated approach to the front end plan- 
ning process. The process estimates projected order 
completion based on customer requested orders. Re- 
quested orders are received and requirements are en- 
tered into the planning system. A check is then made to 

30 see if requirements can be satisfied by either unallocat- 
ed inventory or unallocated schedule production. If the 
results of this check meet the requirements, the infor- 
mation is provided or order promising pending order 
confirmation. If the results on the other hand do not meet 

3S the requirements, the process then utilises the logic of 
a material requirements planning system to explode the 
requirements and generate a statement of time phase 
dependent to requirements. The logic of the material re- 
quirements planning system is used to simulate the 

40 process of procurement and/or fabrication of the neces- 
sary components to calculate possible delivery dates. 
The effect of releasing new order/requirements is further 
simulated by capacity/resource planning logic to verify 
if production capacity is available to meet delivery dates 

45 requested by the customer or suggested by the material 
requirements planning system. Following the simulation 
process, the system provides the order processing op- 
erator clear information on best available dale(s) if re- 
quested, whether the customer specified date(s) can be 

so met, and if customer specified date(s) cannot be met, ' 
the best available date(s). 

European patent application EP-A-0,615,198 de- 
scribes a method for processing, handling and present- 
ing data pertaining to an enterprise in the form of a data 

55 model. The data within that model and the relationships 
are presented, looked at and used from two different 
points of view: from an application point of view that 
identifies which entities ar used by individual program 
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applications, and from an entity point of view which iden- 
tifies all existing entities within a program series and 
their relationships at the different levels of decomposi- 
tion independently of any application. 

In accordance with one aspect of the invention, 
there is provided a system for automatically managing 
available to promise product and making of promises to 
fulfill customer requests from the available to promise 
product, the system comprising: a data storage device 
storing at least one seller model which represents a sell- 
er entity that is selling at least one product; an execution 
memory operable to hold a software system; and a proc- 
essor coupled to the data storage device and the exe- 
cution memory, the processor being operable to execute 
the software system such that the software system op- 
erates: to use the at least one seller model to represent 
a forecast for the number of the at least one product that 
is expected to be sold by the seller and to define com- 
mitment levels for sales of the at least one product in 
order to create forecast requests for the at least one 
product; to provide the forecast requests to supplier 
sites and receive responsive promises made by the sup- 
plier sites to fill the forecast requests; to represent the 
promises made by the supplier sites to the seller entity 
as available to promise product to be used for promising 
to fill actual customer requests; and to adjust the avail- 
able to promise product responsive to any promises 
made to fill actual customer requests; such that the 
available to promise product automatically reflects prod- 
uct that has been promised by a supplier site but not 
promised to a customer. 

In accordance with another aspect of the invention, 
there is provided a system for automatically managing 
available to promise product and making of promises to 
fulfill customer requests from the available to promise 
product, the system comprising: a data storage device 
storing a supply chain model representing a chain of 
supply, the supply chain model comprising: site models 
that represent supplier sites that have capacity; and sell- 
er models that represent seller entities that manage 
forecasting and purchasing; an execution memory op- 
erable to hold a software system; and a processor cou- 
pled to the data storage device and the execution mem- 
ory, the processor being operable to execute the soft- 
ware system such that the software system operates: to 
use the site models to manage material flow; to use the 
seller models to manage forecasting and purchasing; to 
model commitments between supplier sites and sellers 
by requests and promises; and toallow the supplier sites 
to post requests on behalf of seller entities in anticipa- 
tion of future requests from the sellers; such that the sys- 
tem automatically manages available to promise prod- 
uct for the sellers that reflects capacity at the supplier 
sites. 

In accordance with a further aspect of the invention, 
there is provided a system for managing available to 
promise product and making of promises to fulfill cus- 
tomer requests from the available to promise product, 



the system comprising: a data storage device storing a 
plurality of product models each representing a product, 
the product models specifying for each product: a sup- 
plier site, an item produced by that site, a minimum 

5 quantity, a minimum order lead time, a list of customers 
allowed to purchase, and pricing; an execution memory 
operable to hold a software system; and a processor 
coupled to the data storage device and the execution 
memory, the processor being operable to execute the 

10 software system such that the software system oper- 
ates: to fulfill a customer request having desired char- 
acteristics matching a product, as represented by a 
product model, by a promise of the product from avail- 
able to promise product; and to display, as available-to- 

*5 promise product for fulfilling the request, a list of all 
matching products and associated available promise 
quantities. 

An embodiment of the invention enables manage- 
ment of available to promise product (ATP), while sub- 
20 stantially eliminating or reducing disadvantages and 
problems associated with previously developed sys- 
tems. 

One embodiment of the present invention provides 
a system for managing ATP in a distributed organiza- 

25 tion. The distributed organization comprises at least one 
supplying facility such as a factory. Additionally, the dis- 
tributed organization comprises a plurality of requesting 
facilities for each supplying facility. The requesting facil- 
ities may comprise, for example, sales offices. The re- 

30 questing facilities and the supplying facilities may be 
coupled by a computer network. 

In this embodiment, the requesting facilities each 
store forecast orders in a memory of a computer at the 
requesting facility. The forecast orders include request 

35 information. As defined previously, the request informa- 
tion includes the quantity (or range of quantities) of prod- 
uct requested from the supplying facility and the date 
(or range of dates) it is needed. A master scheduling 
software system may be used to selectively plan use of, 
for example, manufacturing capacity of the supplying fa- 
cility to meet selected forecast orders based on prede- 
termined criteria. If a feasible and desirable plan can be 
devised that satisfies the request, then the supplier may 
make a promise to the customer that the supplier will 

45 satisfy the request. The promises to meet the selected 
forecast orders may be transmitted directly to the cus- 
tomers over a computer network. 

In environments where customers are not willing to 
wait fcr a plan to be developed to get a promise, the 

so supplying facility must create promises in advance that 
are available for immediate transfer to a customer. In 
this embodiment, future requests can be forecasted and 
a plan can be made to satisfy and promise those fore- 
cast requests. When an actual customer request is re- 

55 ceived, one or more (or a portion of) promises made to 
forecast requests may be instantly reassigned to the 
customer request. 

An mbodiment of the invention can provide the 
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ability in a distributed organization with distributed sales 
people to allocate some of the promises made to fore- 
cast requests to certain sales people, thereby prevent- 
ing them from simultaneously using the same forecast 
promise as a promise to a customer, without requiring 
them to check with each other before making promises, 
in this embodiment, each sales organization or person 
can be modeled and each forecast request/promise can 
be allocated to one such sales entity. 

An embodiment of the invention can enable the al- 
location of promises to be done for business manage- 
ment reasons. For example, a sales organization may 
be allocated promises based upon how much they are 
willing to commit to selling. This embodiment allows 
each sales entity to create its own forecast of what it 
could sell and establish the level it is willing to commit 
to selling. Forecast requests are then generated from 
the committed levels. Promises made to those requests 
become allocated to that sales entity for it to use to form 
promises for customer requests. 

An embodiment of the invention can allow these 
sales entities to be organized into hierarchies (for ex- 
ample, sales person within sales office within marketing 
organization). Promises that are allocated to a sales or- 
ganization can be used by the sales people within that 
organization. Coordination is required in such cases to 
ensure that two sales people do not consume the same 
promises. But where such coordination is feasible, it is 
typically desirable to have some allocations that are 
common among them. 

An embodiment of the invention can enable custom- 
er requests that cannot currently be promised to be 
queued. As conditions change, the queued requests 
have the first opportunity to be promised. Without such 
a queuing mechanism, requests that cannot be prom- 
ised are forgotten. When new capacity frees, the next 
customer that happens to make a request gets that new- 
ly freed capacity. 

An embodiment of the invention can enable an en- 
tire distributed organization of suppliers and customers 
can be modeled along with the requests and promises 
placed between them. In this way, planners can view, 
manage, and plan the activity of a whole network where 
the interfaces between elements must be formal (sepa- 
rate corporations). 

An embodiment of the invention can enable each 
sales entity to define the "products" it sells, where a 
product is an item priced based on the item, the quantity, 
the order lead time (time from accepting the order to the 
requested due date), and the customer. For each such 
product, an independent forecast and commitment can 
be made, independent forecast requests can be issued, 
and independent promises can be received. In this way, 
promises can be allocated for requests with particular 
characteristics. For example, one product may sell an 
item for $5 if the order lead time is greater than 6 weeks. 
Another product may sell the same item for $10 but with 
as short as 1 week lead time. Thus, a customer request 



with 6 week order lead time may be received when all 
allocations for that product have been consumed. How- 
ever, if all the allocations or the 1 week order lead time 
product have not been consumed, then the customer 

s can be given an option: the next available promise for 
the 6 week order lead time product wculd be 2 weeks 
later than your due date, or alternatively/ you may 
choose to pay $10 for the 1 week order lead time product 
and to receive it on time. Such management of products 

10 can prevent higher future profits for being sold at lower 
profits because they are promised first-come-first- 
served. 

An embodiment of the invention can enable fore- 
cast requests to specify how they expire. Some may 

75 shift out in time if they are not consumed; others may 
expire and disappear if not consumed. Such auto-main- 
tenance of forecast requests can be very valuable in 
maintaining accurate forecasts and allocations for hun- 
dreds or thousands of products. 

20 Embodiments of the invention are described, by 
way of example only, with reference to the following de- 
scription taken in conjunction with the accompanying 
drawings in which like reference numbers indicate like 
features, and wherein: 

25 

FIGURE 1 is a block diagram of one embodiment 
of a supply chain model, including site models and 
seller models, and requests and promises between 
them; 

30 FIGURE 2 illustrates one embodiment of a forecast 
entry for one of several forecast periods for one of 
several products within a seller; 
FIGURE 3 illustrates one embodiment of a time ho- 
rizon with forecast requests and actual requests 

35 showing the time horizon moving as time passes 
and the forecast requests adjusting in response; 
and 

FIGURE 4 illustrates one embodiment of a seller 
model hierarchy and a product group hierarchy 
40 within a seller. 

The Supply Chain. Site, and Seller Models 

Figure 1 is a block diagram of one embodiments of 
■*5 a supply chain model, including site models and seller 
models, and requests and promises between them. 
FIGURE 1 provides an example supply chain according 
to the teachings of the present invention. The supply 
chain model of FIGURE 1 comprises twelve site models, 
so 12, 14, 16, 18, 20, 22, 24, 30, 32, 34, 36, and 38. These " 
site models represent organizational units that may 
have the capacity and materials to produce or consume 
items. Each site can place requests for items upon other 
sites. Requests are in general indicated in FIGURE 1 by 
55 triangles 52, 62, 72, and 74. For each request 52, 62, 
72, and 74, the site 12, 14, 16, 18, 20, 22, 24, 30, 32, 
34, 36, or 38 being requested can make a promise to 
fulfill (wholly or partially) that request. Promises are in 



INSDOCID: <EP 0776509B»_I_> 



4 



7 



EP 0 776 509 B1 



8 



general indicated by inverted triangles 54, 64, and 76. 
Other primary members of a supply chain model are 
seller models. The embodiment of a supply chain of 
FIGUTRE 1 consists of a single seller model 50. 

A seller model 100 is partially depicted in FIGURE 
2 and consists ol a list of products 110 that seller 100 
offers for sale. A product model 110 defines the supplier 
site, the item at that site, a minimum order lead time, a 
minimum quantity, and the allowed customer sites. If a 
customer request fits those criteria of a product, then 
that request is eligible to be filled by that product, at the 
pricing specified by that product. 

FIGURE 2 illustrates one embodiment of a forecast 
entry (or one of several forecast periods for one of sev- 
eral products within a seller. For each product 110, a 
forecast horizon 112 is laid out. Forecast horizon 112 
can be broken up arbitrarily. In this embodiment, three 
t-weck periods (the first being 114) are followed by 
three i -month periods. For each forecast period for 
each product, a forecast-entry 116 is generated. The 
'fotucribted' and 'committed' values can be filled in. The 
value 'forecasted' is the seller's estimate for how much 
could be scld of that product 110 during that period. The 
value 'committed' is the quantity the seller is willing to 
commit to selling. 

Tho committed quantity results in 'forecast' re- 
quests being generated in an amount equal to the com- 
mitted quantity, spread out through the corresponding 
forecast period according to a forecast policy specified 
by the product 110. In the embodiment of FIGURE 2, 
the committed amount results in generation of requests 
120 and 124. spaced out in the period 114. The site on 
which the requests 120 and 124 were placed (specified 
by the product 1 1 0) can then issue promises. Assuming 
promises 122 and 126 are made for requests 120 and 
124. respectively, the value of 'allocated' in the forecast 
entry 1 1 6 lor pertod 1 1 4 will be the sum total of the prom- 
ised quantities. 

The allocated amount is the summary amount the 
seller has available to promise customer requests. 
When customer request 12E arrives to the seller for 
product 110 during period 114, the seller can take one 
or both (or part of one or both) promises that it has al- 
ready received, break them up or combine them to form 
a promise lor the customer request. The forecast re- 
quests are simultaneously adjusted down by the amount 
of the customer request. So, for example, if the commit- 
ted value of forecast entry 116 was 500 units, the two 
forecast requests 1 20 and 1 24 were for 250 units each, 
the two promises 122 and 126 were received for 200 
units, and the customer request 128 was for 300 units, 
then the two forecast requests 120 and 124 will be ad- 
justed to a total of 200 (i.e., 200 and 0 or 100 and 100 
or some other combination, dependent upon the prod- 
uct's forecast policy). The two promises 122 and 126 
will be adjusted to a total of 1 00, and a new promise 1 30 
will be created for 300 units to satisfy request 128. The 
'committed' and 'allocated' values of forecast entry 116 



do not change as a result, but the 'requested' and 'prom- 
ised' values do. When 'promised' is equal to 'allocated', 
then there are no more promises available for promising 
customer requests. 
5 This process is also depicted in the supply chain 
model example of FIGURE 1. In FIGURE 1, seller 50 
generates forecast request 52 on site 22 for delivery to 
site 30 (which need not be a physical site). Request 52 
results in site 22 generating operation 56 to perform the 
activity involved in delivering the requested items to site 
30. If operation 56 is feasible to perform, then site 22 
may choose to create promise 54 to seller 50 that the 
item can be delivered as requested by request 52. 

Site 34 then places request 62 through seller 50 for 
the same product as request 52. If that customer request 
62 is consistent with what seller 50 was forecasting, then 
seller 50 can reduce request 52, promise 54, and oper- 
ation 56 by the amount of request 62, and then add 
promise 64 and operation 66 to fulfill request 62. That 
simple action did not require replanning through site 22. 
Effectively the ability of site 22 to satisfy request 62 had 
been pre-computed in the form of promise 54. Thus, that 
promise 54 can be split in order to form promise 64. 

A primary caveat is that the load and times of the 
operation 56 may not be valid when split into operation 
66. For example, if operation 56 involved using a truck 
to transport the items, then splitting out operation 66 
may result in an additional truck being used. If none was 
available, then operation 66 may have to wait. To com- 
pensate for this, each product defines criteria for split- 
ting promises, which can include an amount of time with 
which to pad the due dates quoted. 

Of the site models that make up a supply chain mod- 
el (as in FIGURE 1 ), some of the sites can be under the 
control of that supply chain model, while others can be 
modeling sites which are planned independently. Afield 
of the site model called 'managed' indicates which sites 
are managed by this supply chain model and which are 
not. Two sites that are both managed do not need to 
make formal promises between each other -- the re- 
quest will generate an operation and all changes to the 
requests are immediately passed through the operation 
to the other site. Requests between a managed Site and 
an unmanaged site require formal promises. The prom- 
ises must be made explicitly, and once accepted consti- 
tute a rigid agreement between two Sites. Changing that 
agreement requires both sites' consensus. 

Adjustment as Time Passes 

Forecasts are often, by their nature, wrong. Thus, 
as time passes and customer requests arrive faster or 
slower than expected, it is desirable to modify the fore- 
casts as appropriate. Given a large number of products 
and numerous forecast periods, automated adjustment 
is highly desirable. 

Thus, the product forecast policy can specify how 
the forecasted and committed quantities should be ad- 
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justed as time passes and actual Requests are received 
or not. 

FIGURE 3 illustrates one embodiment of a time ho- 
rizon with forecast requests and actual requests show- 
ing the time horizon moving as time passes and the fore- 
cast requests adjusting in response. The timeline 200 
represents the initial state. Forecast requests 202, 204, 
206, and 208 have been made in their respective fore- 
cast periods. Customer requests are indicated with tri- 
angles, as shown. The two customer requests 222 cor- 
respond to forecast request 202. The three customer re- 
quests 224 correspond to forecast request 204. 

Time passes and no more requests are received. 
The timeline 210 represents that later state. Time has 
advanced beyond the forecast period of the forecast re- 
quest 202. The customer requests 222 received during 
that period were less than that forecast request. One 
option is to assume the forecast was too high and simply 
expire the leftover forecast. Another option is to assume 
the forecast quantity is right, but that the timing is off 
that the total quantity will be requested soon. In the latter 
case : the forecast request should be moved forward in 
time and reduced in quantity. This is shown as forecast 
request 212. There are many other options for how to 
expire, reduce, or increase forecast requests based on 
the arrival rate of customer requests that can be encod- 
ed in the product's forecast policy. 

Allocation to Sellers 

i 

FIGURE 4 illustrates one embodiment of a seller 
model hierarchy and a product group hierarchy within a 
seller. FIGURE 4 shows two Seller hierarchies. Seller 
410 represents an Industrial Products marketing divi- 
sion, and seller 420 represents a Consumer Products 
marketing division. Within Industrial Products 41 0, there 
are three sales offices that each handle a regions: the 
North is handled by seller 412; the South is handled by 
seller 41 4; the West is handled by seller 41 6. Each sales 
office is made up of numerous sales people, who are 
each represented by a seller (for example, Joe is seller 
418 and Sally is seller 41 9). 

In many organizations, the sellers may own their 
own allocations against which they can promise to their 
customers without consulting the company. However, 
sellers need not own any allocations. For example, Joe 
418 and Sally 419, along with the other sellers in the 
South sales office 414, may each forecast what they in- 
tend to sell. Those forecasts are aggregated up to the 
sales office seller 41 4, where they are used as an input. 
The seller 41 4 can independently forecast for the whole 
sales office. That, in turn, is allocated up to the Industrial 
Products 410 division. 

Clearly, forecast requests should not be generated 
for the forecasts at all three levels -- that would result in 
triple the requests appropriate. 

Instead, each seller can independently commit to 
selling some or all of the forecast. By committing, fore- 



cast requests are created in order to obtain promises 
which can be used to promise their customers. Those 
promises are owned by (or controlled by) that seller that 
committed to selling that amount. 
5 However, it may be that some sellers do not commit 
at all. For example, none of the salespeople, including 
Joe 418 and Sally 419 commit to any of the forecast. 
Instead, the South sales office 41 4 commits as a whole. 
That results in allocations to the South Seller 41 4. Those 
io allocations can be used by any of the sub-sellers, such 
as Joe 418 and Sally 41 9. However, such collective us- 
age of the allocations requires coordination. They must 
reserve the amount they need before they can actually 
promise it, since the other sales people may be consid- 
is ering using the same allocations. 

A seller is committed to anything its sub-sellers 
commit to. However, a seller can commit to additional, 
beyond what the sub-sellers commit to. For instance, 
each sales person may make a conservative commit- 
ment. The sales office will know that some of the sales 
people will surely sell over their commitment, but it is not 
clear which sales people. So the sales office can commit 
to sell additional, and those additional allocations will be 
available to the first sales people who exceed their per- 
sonal allocation. 

Product Groups 

Forecasts tend to be more accurate in aggregate. 
A monthly forecast will generally be more accurate than 
a weekly forecast. A forecast for North America will gen- 
erally be more accurate than a forecast for Texas. Sim- 
ilarly, a forecast for milk will generally be more accurate 
than for skim milk in pint containers. 

Thus, it is important to be able to aggregate up fore- 
casts, modify the aggregated forecasts, and propagate 
the changes back down to the individual products. The 
product group model supports this functionality 

Product groups form hierarchies. A product group 
can have at most one parent product group, and thus 
can be in at most one product group hierarchy. 

Products, on the other hand, can appear in numer- 
ous product groups; however, only in one product group 
of any one hierarchy. A product group defines one con- 
sistent hierarchy for aggregation. However, sellers will 
need to aggregate the products in many different ways. 
For example, milk products can be aggregated by their 
container size (gallon, half gallon, quart, pint), by Their 
fat content (whole, 2%, 1%, skim), by the customer 
grouping (grocery-store, restaurant, convenience- 
store), or by brand (ECONO-COW, PUREWHITE). 

product group s are depicted in FIGURE 4. Prod- 
ucts 450, 452, 454, and 456 are grouped into two prod- 
uct group hierarchies, rooted at product groups 430 and 
440. Product group 430 is broken down into product 
groups 432, 434, and 436. 
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11 EPO 

Advanced Avaiiable-To-Promise (ATP) 

Each seller has allocation (promises) available for 
the various products sold. When a customer request 
comes in to a seller, there may be numerous products 
that match the request, if the lowest cost product can 
fully satisfy the request (has sufficient quantity by the 
requested due date), then the request can simply be 
promised. Otherwise, a decision may be needed. For 
example, the customer may be able to choose to have 
it for a low price but a week later than requested, or by 
the date requested but 10% higher price. It may be that 
half the order can be completed on time at the lowest 
price, but the other half can either be delivered later or 
for a higher price, and so on. Thus, the ATP can be a 
list of different products (pricings) with different order 
lead times, minimum quantities, availability dates, and 
availability quantities. 

Extensible product Model 

The product model type has a forecast policy exten- 
sion selector that allows additional fields and semantics 
to be added to a product model. Extension selectors are 
described in more detail in International patent applica- 
tion WO97/00488 and entitled EXTENSIBLE MODEL 
NETWORK REPRESENTATION SYSTEM FOR 
PROCESS PLANNING having a priority date of 16 June 
1995 and a publication date of 5 January 1997. 

In this way, additional forecast information such as 
forecast error or forecasted variance in either quantity 
or time or both can be input and used. Additional fields 
for expected skew during the month can affect how the 
committed quantity is split out into forecast requests. 
The expected variance or order arrival rates can affect 
how forecast requests expire or adjust as time passes, 
based on the customer requests that have been recei- 
ded. 



Claims 

1. A system for automatically managing available to 
promise product and making of promises to fulfill 
customer requests from the available to promise 
product, the system comprising: 

a data storage device storing at least one seller 
model which represents a seller entity that is 
selling at least one product; 
an execution memory operable to hold a soft- 
ware system; and 

a processor coupled to the data storage device 
and the execution memory, the processor being 
operable to execute the software system such 
that the software system operates: 
to use the at least one seller model to represent 
a forecast for the number of the at least one 
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product that is expected to be sold by the seller 
and to define commitment levels for sales of the 
at least one product in order to create forecast 
requests for the at least one product; 

5 to provide the forecast requests to supplier 

sites and receive responsive promises made by 
the supplier sites to fill the forecast requests; 
to represent the promises made by the supplier 
sites to the seller entity as available to promise 

10 product to be used for promising to fill actual 

customer requests; and 
to adjust the available to promise product re- 
sponsive to any promises made to fill actual 
customer requests; 

*5 such that the available to promise product au- 

tomatically reflects product that has been prom- 
ised by a supplier site but not promised to a cus- 
tomer. 

20 2. The system of Claim 1, wherein the at least one sell- 
er model can further represent a hierarchy, such 
that allocations to a seller entity can be used by the 
seller entity or any sub sellers of the seller entity, 
and such that commitments made by the seller en- 

25 tity to sell product also commit the sub sellers of the 
seller entity. 

3. The system of Claim 1 or Claim 2, wherein the sys- 
tem is a software system located in and executed 
30 by a digital computer, the digital computer compris- 
ing: 

a data storage device; 

an execution memory operable to hold the soft- 
35 ware system; and 

a processor coupled to the data storage device 
and the execution memory, the processor op- 
erable to execute the software system. 

40 4. A system for automatically managing available to 
promise product and making of promises to fulfill 
customer requests from the available to promise 
product, the system comprising: 

45 a data storage device storing a supply chain 

model representing a chain of supply, the sup- 
ply chain model comprising: 
site models that represent supplier sites that 
have capacity, and 

50 seller models that represent seller entities that 

manage forecasting and purchasing; 
an execution memory operable to hold a soft- 
ware system; and 

a processor coupled to the data storage device 
55 and the execution memory, the processor op- 

erable to execute the software system such that 
the software system operates: 
to use the site models to manage material flow; 
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sage verfugbaren Produkten undzum Zusagen, una 
Kundenanforderungen der zur Zusage verfugbaren 
Produkte zu erfullen, wobei das System umfaftt: 

5 eine Datenspeichereinrichtung zum Speichern 

von wenigstens einem Verkaufermodell, wel- 
ches eine Verkauferentitat darstellt, die wenig- 
stens ein Produkt verkauft; 
einen Ausfuhrungsspeicher, urn ein Software- 

10 system zu halten; und 

einen an die Datenspeichereinrichtung und den 
Ausfuhrungsspeicher gekoppelten Prozessor, 
wobei der Prozessor das Softwaresystem aus- 
f uhrt, so daft das Softwaresystem arbeitet: 

75 urn das wenigstens eine Verkaufermodell zu 

verwenden, um eine Vorhersagefurdie Menge 
des wenigstens einen Produktes darzustellen, 
deren Verkauf von dem Verkaufer erwartet 
wird, und um Verpflichtungsebenen fur Verkau- 

20 fe des wenigstens einen Produktes festzule- 

gen, um Vorhersageanforderungen fur das we- 
nigstens eine Produkt zu erstellen; 
um die Vorhersage-Anforderungen an Liefer- 
standorten bereitzustellen und entsprechende 

2S Zusagen, welche von den Lieferstandorten ge- 

macht werden, um die Vorhersage-Anforderun- 
gen zu erfullen, zu empfangen; 
um die durch die Lieferstandorte fur die Verkau- 
fer-Entitat gemachten Zusagen als zur Zusage 

30 verfugbares Produkt darzustellen, welche zum 

Zusagen der Erfullung talsachlicher Kunden- 
anforderungen verwendet werden; und 
um das zur Zusage verf ugbare Produkt als Re- 
aktion auf alle Zusagen einzustellen, die ge- 

35 macht werden, um tatsachliche Kundenanfor- 

derungen zu erfullen; 

so daft das zur Zusage verfugbare Produkt au- 
tomatisch ein Produkt widerspiegelt, das von 
einem Lieferstandort zugesagt wurde, aber 
40 nicht einem Kunden zugesagt wurde. 

2. System nach Anspruch 1 , 

bei welchem das wenigstens eine Verkaufermodell 
weiterhin eine Hierarchie darstellen kann, so daft 

45 Zuordnungen zu einer Verkauferentitat von der Ver- 
kauferentitat Oder Weiterverkaufern der Verkaufe- 
rentitat verwendbar sind, und so daft von der Ver- 
kauferentitat zum Verkauf des Produktes vorge- 
nommene Verpflichtungen ebenfalls die Weiterver- 

50 kaufer der Verkauferentitat verpflichten. 



to use the seller models to manage forecasting 
and purchasing; 

to model commitments between supplier sites 
and sellers by requests and promises; and 
to allow the supplier sites to post requests on 
behalf of seller entities in anticipation of future 
requests from the sellers; 
such that the system automatically manages 
available to promise product for the sellers that 
reflects capacity at the supplier sites. 

5. The system of Claim 4 wherein the software system 
further operates to manage a queue that allows re- 
jected requests to be queued for consideration 
whenever capacity frees up. 

6. A system lor managing available to promise product 
and making of promises to fulfill customer requests 
from the available to promise product, the system 
comprising. 

a data storage device storing a plurality of prod- 
uct models each representing a product, the 
product models specifying for each product: a 
supplier site, an item produced by that site, a 
minimum quantity, a minimum order lead time, 
a list of customers allowed to purchase, and 
pricing: 

an execution memory operable to hold a soft- 
ware system; and 

a processor coupled to the data storage device 
and the execution memory, the processor op- 
erable to execute the software system such that 
the software system operates: 
to fulfill a customer request having desired 
characteristics matching a product, as repre- 
sented by a product model, by a promise of the 
product from available to promise product; and 
to display as available-to-promise product for 
fulfilling the request, a list of all matching prod- 
ucts and associated available promise quanti- 
ties. 

7. The system of Claim 6, wherein at least one product 
model specifies an extension allowing different 
forecast information to be recorded and used to 
compute and distribute forecast requests. 

8. The system of Claim 7, wherein the at least one 
product model specifies expiration and adjustment 
semantics for forecast requests as time passes and 
as actual customer requests arrive faster or slower 
than expected. 



Patentanspruche 

1 . System zum automatischen Verwalten von zur Zu- 



3. System nach Anspruch 1 oder Anspruch 2, 

bei welchem das System ein Softwaresystem 
ist, welches angeordnet ist in und ausgefuhrt 
wird von einem Digitalcomputer, wobei der Di- 
gitalcomputer umfaftt: 
eine Datenspeichereinrichtung; 
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einen Ausf uhrungsspeicher, welcher das Soft- 
waresystem halt; und 

einenan die Datenspeichereinrichtung undden 
Ausfuhrungsspeicher gekoppelten Prozessor, 
wobei der Prozessor das Softwaresystem aus- 5 
fuhrt. 

4. System zum automatischen Verwalten von zur Zu- 
sage verfugbaren Produkten und Ausfuhren von 
Zusagen , urn Kundenanforderungen des zur Zusa- 10 
ge verfugbaren Produktes zu erfullen, wobei das 
System umfaBt: 

eine Datenspeichereinrichtung zum Speichern 
eines Lieferkettenmodells, welches eine Liefer- is 
kette darstellt, wobei das Lieferkettenmodell 
umfaBt: 

Standortmodelle, welche Lieferer-Standorte 
darsiellen, die eine Kapazitat aufweisen; und 
Verkaufermodelle : die Verkaufer-Entitaten dar- 20 
stellen, die Vorhersagen und Verkauf verwal- 
ten; 

einen Ausfuhrungsspeicher, welcher ein Soft- 
waresystem halt; und 

cincn an die Datenspeichereinrichtung und den 25 
Ausfuhrungsspeicher gekoppelten Prozessor, 
wobei der Prozessor das Softwaresystem aus- 
fuhrt, so daB das Softwaresystem ablauft: 
urn Standort-Modelle zum Verwalten des Ma- 
terialflusses zu verwenden; 30 
urn die Verkauf ermode He zum Verwalten der 
Vorhersagen und des Verkaufes zu verwen- 
den, 

urn Verpflichtungen zwischen Lieferer-Stand- 
orten und Verkaufern durch Anforderungen und 35 
Zusagen nachzubilden; und 
urn den Lieferer-Standorten zu ermoglichen, 
Anforderungen anstelle der Verkaufer-Entita- 
ten in der Vorwegnahme zukunftiger Anforde- 
rungen von den Verkaufern zu plazieren; so *o 
daB das System automatisch zur Zusage ver- 
fugbare Produkte fur die Verkaufer verwaltet, 
welche die Kapazitaten an den Lieferer-Stand- 
orten widerspiegeln. 

45 

5. System nach Anspruch 4, 

bei dem das Softwaresystem weiterhin arbeitel um 
eine Warleschlange zu verwalten, welche ermdg- 
licht, daB zuruckgewiesene Anforderungen zur Be- 
rucksichtigung bei freiwerdenden Kapazitaten ein- so 
gereiht werden. 

6. System zum Verwalten von zur Zusage verfugbaren 
Produkten und zum Zusagen, um Kundenanforde- 
rungen der zur Zusage verfugbaren Produkte zu er- ss 
fullen, wobei das System umfaBt: 

eine Datenspeichereinrichtung zum Speichern 
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mehrerer Produktmodelle, von denen jedes ein 
Produkt darstellt, wobei die Produktmodelle fur 
jedes Produkt festlegen: 
einen Lieferer-Standort, ein an diesem Stand- 
ort erzeugtes Element, eine kleinsteMenge, ei- 
ne kurzeste Auftragsvorlaufzeit, eine Liste von 
zur Belieferung zugelassenen Kunden und 
Preise; 

einen Ausfuhrungsspeicher zum Halten eines 
Softwaresystems; und 

einen an die Datenspeichereinrichtung und den 
Ausfuhrungsspeicher gekoppelten Prozessor, 
wobei der Prozessor das Softwaresystem aus- 
fuhrt, so daB das Softwaresystem ablauft: 
um eine Kundenanforderung mit gewunschten 
Merkmalen, welche mit einem Produkt uberein- 
stimmen, wie von einem Produktmodell darge- 
stellt, durch eine Zusage des Produktes des zur 
Zusage verfugbaren Produktes zu erf ullen; und 
um als zur Zusage verfugbares Produkt zum 
Erfullen der Anforderung eine Liste alter uber- 
einstimmenden Produkte und zugeordneter 
verf ugbarer Zusagemengen anzuzeigen. 

7. System nach Anspruch 6, 

bei weichem wenigstens ein Produktmodell eine Er- 
weiterung festlegt, welche die Aufzeichnung und 
die Verwendung verschiedener Vorhersageinfor- 
mationen zum Berechnen und Verteilen der vorher- 
gesagten Anforderungen erlaubt. 

8. System nach Anspruch 7, 

bei weichem das wenigstens eine Produktmodell 
Auslauf- und Einstell-Semantik fur Vorhersage -An- 
forderungen festlegt, wenn Zeit verstreicht, und 
wenn eine tatsachliche Kundenanfrage schneller 
oder langsamer als erwartet eintrifft. 

Revendications 

1 . Systeme de gestion automatique de produit dispo- 
nible a la vente et de passage de promesses pour 
la satisfaction de demandes de clients a partir du 
produit disponible a la vente, le systeme compre- 
nant: 

un dispositif de memorisation de donnees me- 
morisant au moins un modele de vendeur, qui 
represente une entite vendeuse vendant au 
moins un produit; 

une memoire d'execution apte a contenir un 
systeme logiciel; et 

un processeur couple au dispositif de memori- 
sation de donnees et a la memoire d'execution, 
le processeur etant apte a executer le system 
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logicie! d'une facon telle, que le systeme logi- 
ciel fasse en sorte: 

d'utiliser le ou les modele(s) de vendeur pour 
representer une prevision pour le code du ou s 
des produit(s) que le vendeur s'attend a vendre 
et pour definir des niveaux d'engagement pour 
des ventes du ou des produit(s), afin de creer 
des demandes previsionnelles pour le ou les 
produit(s); io 

de delivrer les demandes previsionnelles a des 
sites fournisseurs et de recevoir, en reponse, 
des promesses faites par les sites fournisseurs 
pour satisfaire les demandes previsionnelles; is 

de representer les promesses faites par les si- 
tes fournisseurs a I'entite vendeuse comme 
correspondant a du produit disponible a la ven- 
te, devant etre utilise pour promettre de satis- 20 
faire des demandes reelles de clients; et 

d'ajuster le produit disponible a la vente en re- 
ponse a des promesses faites pour satisfaire 
des demandes reelles de clients; 25 

de telle sorte que le produit disponible a la ven- 
te reflete automatiquement le produit qui a ete 
promis par un site fournisseur, mais qui n'a pas 
. ete promis a un client. 30 

Systeme selon la revendication 1 , dans lequel le ou 
les modele(s) de vendeur peuvent, en outre, repre- 
senter une hierarchie, de telle sorte que des affec- 
tations a une entite vendeuse puissent etre utilisees 35 
par I'entite vendeuse ou par tout sous-vendeur de 
I'entite vendeuse, et de telle sorte que des engage- 
ments a vendre du produit, pris par I'entite vendeu- 
se, engagent egalement les sous-vendeurs de I'en- 
tite vendeuse. 40 

Systeme selon la revendication 1 ou la revendica- 
tion 2, dans lequel le systeme est un systeme logi- 
ciel place dans et execute par un calculates nume- 
rique, le calculates numerique comprenant: *s 

5. 

un dispositit de memorisation de donne"es; 

une memoire d'execution apte a contenir le 
systeme logiciel; et so 

un processes couple au dispositif de memori- 6. 
sation de donnees et a la memoire d'execution, 
le processes etant apte a executer le systeme 
logiciel. ss 

Systeme de gestion automatique de produit dispo- 
nible a la vente et de passage de promesses pour 



la satisfaction de demandes de clients a partir du 
produit disponible a la vente, le systeme compre- 
nant: 

un dispositif de memorisation de donnees me- 
morisant un modele de chaine d'offre represen- 
tant une chaine d'offre, le modele de chatne 
d'offre comprenant: 

des modeles de site representant des sites 
fournisseurs qui disposent d'une capacite; et 

des modeles de vendeur representant des en- 
tites vendeuses qui gerent les previsions et les 
approvisionnements; 

une memoire d'execution apte a contenir un 
systeme logiciel; et 

un processes couple au dispositif de memori- 
sation de donnees et a la memoire d'execution, 
le processeur etant apte a executer le systeme 
logiciel d'une fagon telle, que le systeme logi- 
ciel fasse en sorte: 

d'utiliser les modeles de site pour gerer le flux 
de matieres; 

d'utiliser les modeles de vendeur pour gerer les 
previsions et les approvisionnements; 

de modeliser des engagements entre des sites 
fournisseurs et des vendeuses. par des de- 
mandes et des promesses; et 

de permettre aux sites fournisseurs d'inscrire 
des demandes pour le compte d'entites ven- 
deuses, de facon a anticiper sur de futures de- 
mandes en provenance des vendeurs; 

de telle sorte que le systeme gere automatique- 
ment le produit disponible a la vente pour les 
vendeurs, qui reflete la capacite aux sites four- 
nisseurs. 

Systeme selon la revendication 4, dans lequel le 
systeme logiciel intervient en outre pour gerer une 
file d'attente, qui permet a des demandes rejetees 
d'etre mises en attente afin d'etre prises en consi- 
deration chaque fois que de la capacite se libere. 

Systeme de gestion de produit disponible a la vente 
et de passage de promesses pour la satisfaction de 
demandes de clients a partir du produit disponible 
a la vente, le systeme comprenant: 

un dispositif de memorisation de donnees me- 
morisant une pluralrte de modeles de produit 
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representant chacun un produit, les modeles 
de produit specifiant pour chaque produit: un 
site fournisseur, un article produit par ce site, 
une quantite minimum, un delai de livraison mi- 
nimum, une liste de clients autorises a acheter s 
et le prix fixe; 

une memoire d'execution apte a contenir un 
systeme logiciel; et 

un processeur couple au dispositif de memori- 
sation de donnees et a la memoire d'execution, 
le processeur etant apte a executer le systeme 
logiciel d'une facon telle, que le systeme logi- 
ciel fasse en sorte: 

de satisfaire une demande d'un client, qui pre- 
sente des caracteristiques souhaitees concor- 
dant avec un produit repr^sente" par un modele 
de produit, au moyen d'une promesse de vente 20 
du produit a partir du produit disponible a la 
vente; et 

d'afficher, en tant que produit disponible a la 
vente destine a satisfaire la demande, une liste 2s 
de tous les produits concordants et des quan- 
tites associees disponibles a la vente. 

7. Systeme selon la revendication 6, dans lequel au 
moins un modele de produit specifie une extension 30 
permettant a diverses informations previsionnelles 
d'etre enregistrees et utilisees pour traiter et distri- 
buer des demandes previsionnelles. 

8. Systeme selon la revendication 7, dans lequel le ou 35 
les modele(s) de produit specifient une semantique 
d'expiration et d'ajustement pour des demandes 
previsionnelles, au fur et a mesure que le temps 
s'ecoule et que des demandes reelles de clients ar- 
rivent plus vite ou plus lentement que ce qui etait 40 
prevu. 
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